Java Platform, Enterprise Edition (Java EE) (the latest version of which is known as Java EE 5—the previous version was known as Java 2 Enterprise Edition, abbreviated to J2EE) is a set of coordinated technologies and practices that enable solutions for developing, deploying, and managing multi-tier, server-centric applications (especially distributed applications in which different components of the overall application run separately from one another). Building on Java Platform, Standard Edition (Java SE), Java EE adds the capabilities that provide a complete, stable, secure, and fast Java platform for the enterprise. Java EE significantly reduces the cost and complexity of developing and deploying multi-tier solutions, resulting in services that can be rapidly deployed and easily enhanced.
Note that throughout this specification the term object will be used to refer to a computer program construct having various properties well known to persons skilled in the art of object oriented programming of which Java is a well known and commercially important example. Although the described embodiments of the present invention relate specifically to Java, it will be apparent that the invention is more generally applicable, especially as regards other object oriented programming languages.
In essence, Java EE enables an enterprise to develop a server application without needing to generate complex software for handling many of the functions generally required by server applications (e.g. of enabling connections to be made to the server application from remote clients, of providing security features to restrict access to features which only an administrator of the system should have access, etc.).
In particular, an enterprise may develop a server application by generating a number of small software modules known as “Enterprise Java Beans (EJBs)” which are fairly specific to the particular application. The EJB's are then “placed” into an EJB container which is an environment for running EJBs. The EJB container takes care of most of the low-level requirements of the application (e.g. implementing security and enabling remote clients to access the application).
A number of different types of EJB are typically used to generate an application. There are three main different types of enterprise bean: Session beans, Entity beans and Message driven beans.
Session beans are generally used to implement “business logic”—i.e. functions such as looking up data from a database and manipulating it to generate an output which is provided to a remote client. Session beans can either be stateless or “stateful”. Stateless session beans are distributed objects that do not have state associated with them thus allowing concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. Stateful session beans are distributed objects having state. The state can be persisted, and access to a single instance of the bean is limited to only one client.
Entity beans are distributed objects having persistent state. They are generally used to represent an item of business specific data, especially data about a specific business entity (e.g. a piece of network equipment). In general, the persistent state may or may not be managed by the bean itself. Beans in which their container manages the persistent state are generally said to be using Container-Managed Persistence (CMP), whereas beans that manage their own state are said to be using Bean-Managed Persistence (BMP). In both cases the “persistence” is generally performed using a relational database as the backend data store and using an Object to Relational Mapping (ORM) function to convert between the object(s) associated with the entity beans and the backend relational database store. A particularly oft used ORM is Hibernate (see www.hibernate.orq for more details of this product).
Message Driven Beans are distributed objects that respond to Java Messaging Service (JMS) messages. JMS is a standard part of the Java EE platform which enables java objects (typically on remote devices) to asynchronously communicate with one another by sending messages between them. Message beans were added in the EJB 2.0 specification to allow event-driven beans.
A distributed server application may also include a type of object called a Managed bean, or Mbean. These are separate things to EJBs and are typically used to represent an application or device which an administrator would like to be able to remotely manage while the device and/or application is running.
Since the rapid uptake of the internet and the overlying World Wide Web (WWW), the paradigm of distributed processing has been taken from a favourable method, to one that now tackles large management problems in large networks and a common method of designing applications. The ability to distribute a system allows for a delegation of resources, processing and even operational logic (that can be regarded as black box functionality) to other components and also allows duplication of components in different locations to provide redundancy.
With the uptake of the distributed paradigm though comes an increasing dependency; the lack of availability of a component can cost businesses customers, time and money. This means that components have to be readily available, redundant to allow for load and reliability, and perhaps most importantly; externally constant. The necessity for constancy stems from the lack of knowledge regarding systems that are dependent upon the component. Across a business-to-business (B2B) interface only the integration expert that originally coupled the two systems knows the effects of changing either of the two communicating components, and in his absence the upgrade of either component will be shied away from (opting for legacy support instead), or will require extensive and expensive analysis and then almost certainly the requirement for another adapter, B2B interface or mid-way component to be constructed. Such additions solve the immediate problem, but tend to obfuscate further the interaction between the two components should a further change be required.
But in the modern environment, particularly with web-based systems, there is so much change and redefinition that was not picked up with initial requirement analysis, in such a short period of time, that updates are not only necessary, but required increasingly more frequently.
This is true not only for wide scale (Wide Area Network (WAN) based) distributed applications, but also on same-host locally distributed applications. The popularity of container-based logic, brought to popular use by JAVA EE-type servers, uses a distributed-type paradigm in a local sense in order to separate systems' business logic into a series of process components that have instances managed by a container, and interrelate through message passing. This type of distribution is just as vulnerable to the dangers of updating; a single component unavailable can render the system unavailable or worse still erroneous. Although there should be more knowledge of the systems (i.e. all the code should still be available for the system), external interactions can still introduce data to the system that can stress it in unpredicted ways. Adding or updating components themselves still leaves downtime (during the replacement of a component) and could cause loss of instances or a processing chain if there were active instances running prior to the update. Varying from server type to server type, it can be very difficult to just deploy one component of an application at a time; there is no uniform standard in JAVA EE for component replacement or indeed how to deploy an application.
Current methodologies to try and maintain “zero downtime” when updating or modifying a distributed application include server clustering of JAVA EE resources and federated applications. Both revolve around the concept of there being several servers running the same service or application. When an update is needed to be made, a server by server migration is conducted until all the hosts for the application are running the new version. This does allow for deployment analysis, and ensures that at no point is the service unavailable to the clients. What it doesn't ensure is ability to revert the logic after the update is complete, should an error be found. Also, although federating across multiple servers guarantees “zero down-time”, the propagation time for the new logic could be sufficient to allow for a second update to occur during the period, which could lead to significant versioning issues. Furthermore, it generally requires the enterprise to have a number of physical computers, which can be expensive for small enterprises.
Clustering and federation do not take any further steps to allow for integration or extension of data types within the system. Receiving classes that have been previously unspecified is possible, and they can be handled, however should these then need to be persisted they would have to undergo a transformation to a known similar class (which is no simple task and is likely to involve a loss of data) or cannot be stored at all (due to the possible lack of presence in the received class in the system libraries).